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Abstract 

In live streaming systems (IPTV, life-stream services, etc.), an attrac- 
tive service consists in allowing users to access past portions of the stream. 
This is called a time-shifted streaming system. In our vision, a centralized 
time-shifted streaming system face scalability and ethical issues, there- 
fore, we address the problem of designing a peer-to-peer system where 
peers store and deliver past chunks. We first attempt to identify the main 
characteristics of time-shifted streaming system from well-known measure- 
ments of VoD and IPTV systems. These overlays are the first structures 
specifically designed for time-shifted streaming system. Although no eval- 
uation is presented, these preliminary description aim to foster discussions 
on a critical service. 



1 Introduction 

Context. The omnipresence of live streams (i.e., streams that are continuously 
produced from fresh content) represents a challenging trend of the Internet. A 
tremendous scientific literature deals with live video streaming systems in the 
perspective that video streams will soon represent a large majority of the whole 
Internet traffic Tj. Still, other forms of live streams are emerging, in particular 
new forms of life-stream. The concept originally coined by Vannevar Bush [2J 
is currently revisited by popular social network tools like twitter: every user 
is a producer of a life-stream, a stream of personal data that is inherently 
made public in order to be consumed by friends. Should life-streams joint with 
multimedia data generated by passive life experience capturing systems [3] , the 
traffic related with these life-stream applications could become huge. In parallel, 
the proliferation of sensors and the rise of the Internet of things are expected 
to generate also a large amount of data streams [I] . Without loss of generality, 
we assume in this paper live streams consisting of a continuous series of chunks 
that are generated by a producer (or source). 

Problem. In most cases, these live streams are immediately consumed by 
some clients, the delivery at large scale being ensured by multicast protocols, 
powerful data-center or peer-to-peer exchanges. A critical service consists, how- 
ever, in allowing clients to access past portions of a live stream. In the context of 
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IPTV, this is called the time-shifted television: clients start watching a TV pro- 
gram from the beginning although the live program has already started or been 
finished. This feature is currently offered by several public TV broadcasters on a 
part of their history, though these services will probably soon apply soon to the 
whole history, especially for life-streams and sensor-generated streams. Please 
note that the client may choose any past stream portion, the past portion is 
not restricted to the stream that the client may have previously downloaded. 

We distinguish the stream producer, which continuously generates the con- 
tent, and the stream provider, the entity responsible both to continuously store 
the whole stream in a persistent manner, and to serve clients issuing requests on 
past stream portion. A stream producer can rarely be a stream provider, e.g., 
when the producer is a set of tiny sensors or a frequently disconnected individ- 
ual. Besides, a stream provider based on a centralized architecture admits some 
drawbacks. First, the upload bandwidth requirement is very high, because, 
contrarily to live streaming systems, time-shifted streaming systems can not 
directly use group communication techniques like multicast protocols or peer- 
to-peer systems, for the reason that clients require here distinct portions of the 
stream. Moreover, sensitive life-streams or personal sensor-generated streams 
highlight the ethical limitations of private data-centers: lesser privacy protec- 
tion, data lock-in or third-party control. Therefore, in this paper, we address 
the design of a peer-to-peer provider for time-shifted streaming. 

Related Works. The studies related to life-streams or sensor-generated 
streams have mainly assumed that stream producer and provider are the same 
entity. They focus on information retrieval techniques to improve search into 
stream history [3] [5] . Time-shifted video streaming has only recently been ex- 
plored. Enhancements to streaming servers are proposed in [6]. The scalability 
issue of centralized architectures is temporarily tackled by the use of proxy 
caches in [7]. Cache replication and placement schemes are extensively stud- 
ied by the authors of [8|. Finally, when several clients share the same Internet 
access, a patching technique described in [OJ can be used to handle several 
concurrent requests on the same stream. A couple of preliminary works have 
sketched a peer-to-peer architecture for time-shifted TV systems. In [TO], every 
client stores all downloaded video chunks. A Distributed Hash Table (DHT) is 
used to keep trace of the owner of every chunk, so that a peer able to upload 
a past video chunk can be found upon a simple request to the DHT. Similarly, 
a DHT is used to locate video chunks in [11] . Some additional proxies aim to 
ensure the continuity of video that are locally downloaded. These works appear 
to suffer from several crucial drawbacks. At first, the use of a DHT is actually 
irrelevant in this context. Indeed, two peers that are responsible of two consec- 
utive chunks are not linked anyhow. Therefore, downloading a long portion of 
past video requires to send numerous consecutive requests to the peer-to-peer 
structure. Moreover, for every received chunk, a peer should notify the DHT, 
which is quite costly. Finally, the number of video replica is not guaranteed. 

Contributions. This paper is made of two independent parts. First, we 
describe the main characteristics of time-shifted streaming with a specific focus 
on time-shifted IPTV systems. Unfortunately, no measurement on time-shifted 
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Figure 1: Use cases of time-shifted IPTV systems 



IP TV have been published, so we composed from well-known characteristics of 
both live and Video-on-Demand streaming systems to conjecture the behavior of 
clients in time-shifted streaming systems. Second, we propose two peer-to-peer 
providers for time-shifted streaming systems. The first system is a structured 
system, namely turntable, that distributes on a set of network elements the 
task of the provider. That is, elements that are not client of the system can 
also participate to the storage, for example network operators may use some 
controlled set-top-boxes to raise a distributed time-shifted streaming system. 
The second one, namely interval overlay, uses exclusively the storage capacity 
of clients. The goal here is to ensure that all chunks are actually saved and 
available, while the cost is well distributed among clients. 

2 Time-shifted IPTV Systems 

The goal of this section is to characterize time-shifted streaming systems, i.e. 
describing the main use-cases, revealing typical client behaviors and popularity 
trends, and finally estimating the capacity requirements. We focus on peer-to- 
peer time-shifted IPTV systems because (i) IPTV systems have been extensively 
studied recently, so our conjectural analysis can base on proved existing facts, 
(n) IPTV is currently the most attractive and challenging application. 

2.1 Use Cases 

Figure Q] depicts use cases of time-shifted IPTV systems. The y-axis represents 
the playing time of the video source, and the £-axis shows the time lag distri- 
bution of playing positions with the source at a particular time. The shaded 
area denotes the time range for the live streaming service, that is, peers in this 
area are synchronous with the source, but with a small time lag because of the 
buffer mechanism and network delay. The small black points denote the playing 
positions of peers in the system, and the rectangle with shadow presents a data 
chunk. 

In an idle context, peers and source are shifting with the same direction and 
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Figure 2: Population size vs. time lag (with shows) 



a uniform velocity. So the time lags between peers and the source are constant 
from time to to t±. From the viewpoint of chunks in case (1), chunks move 
along x-axis at the same speed as the source that continues outputting new 
content. Therefore, between time to and time t\, a chunk moves t\ — to far from 
the stream producer. In television, the stream is basically cut into successive 
shows (news, movie, sport event, etc.). In this example, we represent four shows 
(showi, shoiV2, shows and shown). From time to to t\, the four shows move 
ti — to far from the source. 

We detail now the main events that are possible for a peer x in a time-shifting 
stream system. They are commonly referred to as VCR operations. 

Pause: it occurs when a user leaves for a moment and is expected to resume 
streaming later from this current position. This is represented by case (2) in 
Figure [T] If the peer x performs a pause at time to and continues playback at 
time ii, the lag between x and the source will increase by ti — to. This operation 
is implemented in current live streaming systems. In these systems, x continues 
to download the fresh content and buffers it. 

Forward and Backward: a viewer in time-shifted IPTV system can perform 
forward or backward operations inside a show, as depicted in cases (3) and 
(4), or between different shows in cases (5) and (6). We distinguish these two 
scenarios because both starting and ending times of a show are special points 
where the behavior of clients can be very different from other stream positions. 

Churn: a peer x may join the system as a live client, but it can also imme- 
diately start at a past position. As in other peer-to-peer systems, a peer should 
be assumed to be able to leave at any time, sometimes abruptly. We highlight 
however in the case (7) that it is also more probable that peer leaves at the end 
of a show, as it has been shown in recent studies [12] . 

2.2 Trends on User Behavior 

To the best of our knowledge, no measurement study dealing with time-shifted 
IPTV systems has been published yet. However, we observe that this service 
combines somehow the real-time property of IPTV and the flexibility of VoD 
applications. Therefore we match the related characteristics of IPTV and VoD 
systems to highlight expected behavior of clients using a time-shifted IPTV 
systems. Note however that some of the ideas extracted from these well-known 
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measurements are in contradiction with the aforementioned previous works on 
peer-to-peer time-shifted video systems. 

Stream Popularity: the relevance of Zipf distribution to describe the popular- 
ity of content in current large-scale applications has been widely demonstrated. 
It applies also to both IPTV [T3] and VoD systems [T3]. For time-shifted video 
streaming systems, it is reasonable to expect that streams will exhibit Zipfian 
popularity distribution. For very popular streams, the storage capacity can be 
neglected in comparison to the upload bandwidth requirement. In the opposite 
for the huge number of unpopular streams, the required storage can become the 
main problem. This differences may lead to distinct strategies. 

Show Popularity: in the same manner, the popularity of different shows in 
a channel could be similar to VoD systems. Figure [2] represents a conjectured 
situation where the population varies with the popularity distribution of the 
shows in a channel. In [15j . a peak has been identified at the beginning of each 
show. Then, as can be also stated in VoD systems, the number of watchers 
decreases, because a portion of viewers often surf the beginning of shows or 
leaves after few minutes. Note that the populations are probably different for 
distinct shows . 

Churn: the spikes of departure have been shown to occur mostly either 
at the end of the show, or because the user does not find any interest after 
browsing the beginning of the show. That is, peers usually leave immediately, 
or simultaneously at the end of programs in [12j . Moreover, a large number of 
sessions end in the first minute, which means that these clients are not interested 
in the shows after browsing through the beginning. In this study, it is shown 
that more than half of the population quits during the first ten minutes of a 
show in average. Moreover, in most cases, the more popular is the show, the 
shorter is the session length. 

2.3 System Perimeters 

If we assume that the size of each chunk is 2 MBytes and the source video rate 
is 500 Kbps [16], the number of chunks that should be stored in one day is 
approximately 2, 700, so it represents more than 5 GBytes of video data. These 
numbers are respectively 80,000 and 160 GBytes for one month for only one 
stream. The amount of data that should be handled in time-shifted streaming 
system are several orders of magnitude larger than in VoD systems. That is, it 
is not surprising that many issues that can be easily tackled in VoD peer-to-peer 
systems can hardly find solutions in our context. 

The approaches commonly used in peer-to-peer VoD systems to store data 
can be roughly classified into two categories: distributed data storage (e.g. [T7]). 
and sliding window buffering (e.g. |18j). 

In the distributed data storage, each peer is assigned to store some video 
chunks and serve other peers. Ideally, a peer is assigned to a small amount of 
chunks, therefore the impact of downloading them initially can be neglected, 
while it can not in time-shifted systems. Moreover, the total number of chunks 
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is fixed in VoD systems, although fresh chunks should continuously be treated 
in time-shifted streaming systems. 

In the sliding window buffering, each peer caches the past downloaded chunks 
for a period of time before discarding them. It serves other peers with this 
cached content. This cache corresponds to a sliding buffer window with a fixed 
size, from the upcoming chunks that will be soon played to the chunks that 
have been played not so recently. In these systems, peers whose buffers overlap 
are likely to exchange data. However, in comparison to VoD systems where 
the typical video duration is not long, time-shifted streaming systems apply on 
far much longer time. Several issues immediately raise: how to ensure that a 
unpopular past portion of the stream is covered by at least one sliding buffer, 
how to dimension the buffer size, etc. 

3 Our Proposals 

Our purpose is to build a distributed time-shifted streaming system. We call 
peer an entity having both storage and network capabilities. We aim to utilize 
the upload bandwidth of peers to reduce the bandwidth burdens placed on the 
server. Among the peers, we distinguish the clients, who are also consuming 
the stream, and other elements that are generously contributing to the system 
without immediate reciprocity (for example, a set-top-box controlled by a net- 
work operator). We neglect here the selfish behavior of peers, that is, we do 
not design any incentive to prevent free-riders. Then, we say that a client can 
be either a live client (consuming the live stream) or a hookup client (consum- 
ing a past portion of the stream). The delivery of the live content (multicast, 
peer-to-peer, etc.) is out of the scope of this paper. Rather, we focus on serving 
the hookup clients. Please note that a VCR operation can make a live client 
become a hookup client, and vice versa. 

Wc identify three main challenges in peer-to-peer time-shifted streaming 
systems: (i) how to store the continuous content output from the source; (ii) 
how to guarantee that every past chunk is still available in the system; (iii) how 
to retrieve a series of successive chunks from a past stream portion. We propose 
two possible approaches: a distributed turntable structure and an interval graph 
structure. 

3.1 Distributed Turntable Structure 

We propose first a structured system based on a turntable. See Figure [3] for 
a representation. The main idea is as follows. We divide the turntable into 
m sectors noted Si,0 < i < to. Every peer joins a sector. The turntable 
implements a rotational motion in clockwise direction. At every time t, the 
producer, noted p, produces a new chunk that is sent to peers in a sector Si, 
then the chunk produced at time t + 1 is sent to sector sj with j = (i + 1) 
mod to, and so orQ. Hence, every new chunk is stored by a subset of peers. See 

1 in the following, we omit the modulo for notation clarity. 
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Figure 3: The distributed turntable structure 



Table Q] to see a typical distribution of chunks to sectors. When a client wants 
to download any past portion of the stream, it should first determine the sector 
associated with the first chunk of this portion. After finding a peer that has 
stored the requested chunks in this sector, the peer can begin to download the 
stream. It should then jump to the next sector in order to retrieve the next 
chunk and continues consuming the stream. 



Sector Id 


Chunk Id 



1 

m — 1 


to 2to 

1 TO + 1 2to + 1 

to — 1 2m — 1 3to — 1 



Table 1: The chunk distribution in the turntable 



The producer must be connected to at least one peer in every sector. These 
peers are called representant. When it is time for a sector Sj to download and 
store a chunk, the source alerts the representants for Si and sends the chunk to 
them, then this chunk is diffused in the sector. The overall structure overlay 
formed by the turntable structure depends on how peers are linked inside a 
sector, which are called the intra-sector links, and how peers from one sector 
are linked to peers of the next sector, namely the inter-sector links. 

The main purpose of the intra-sector links is to allow an efficient diffusion of 
fresh chunks into one sector. Moreover, the overlay formed by intra-sector links 
should also serve to implement a mechanism aiming to ensure a fair allocation 
of the past chunks. Indeed, past chunks concentrate on oldest peers, so oldest 
peers attract requests. This uneven request distribution may not reflect peer 
capacities (old peers may have a lower upload capacity than the new ones). 
Ideally, the number of replicas of a chunk should correspond to the number of 
requests emitted for the stream portion this chunk belongs to. 
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Figure 4: The tree-based overlay structure 

The inter-sector links aim to ease the retrieval of consecutive chunks. A client 
x downloading a past stream portion will produce many successive requests to 
successive past chunks. The purpose of an inter-sector link is to connect two 
peers that are in successive sectors and that store some successive chunks from 
past stream portions. When x is served by a node yi G Sj, its next request will 
be in sector s^+i, i.e. x should find in sector Sj+i a peer that stores the chunk 
next to the one it just downloads from yi. Ideally, the peer y%+\ 6 Si+i to which 
yi is connected stores the next chunk that x will request, so yi can introduce 
j/i+i to x and save request messages. 

We describe in the following two possible implementations: a tree-based (see 
Figured]) an d a mesh-based (see Figure[5]) overlays for every sector. Please note 
that, for clarity reasons, we do not give further implementation details, this is 
left for future works, especially a comprehensive system evaluation. 

3.1.1 Tree-Based Turntable 

The first proposal is to build, into every sector, a logical tree rooted on the 
producer, where the representants are immediate children and other peers self- 
organize to build a tree. In this configuration, the intra-sector links form m 
independent trees for m sectors. Thus, when representants receive a chunk from 
the producer, this chunk can be optimally diffused to all peers in the sector. 
Various optimization algorithms can be used in our context. In particular, 
algorithms for building minimum-cost spanning trees can help to diminish the 
network cost to span all peers (e.g., the number of Autonomous Systems (AS) 
traversed by a chunk in the tree). Another optimization consists in matching 
the capacity of peers (e.g., upload bandwidth) and their position in the tree 
(e.g., the level). 

We propose also to implement a mechanism that allows every peer to know 
all the replicas that are currently stored in the sub-tree rooted on it. This 
can typically be implemented without much efforts with transmission of Bloom 
Filters where an entry i corresponds to whether the ith chunk is guaranteed to 
be found in at least one descendant. The purpose of this mechanism is twofold: 
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(i) if a chunk is missing at the highest levels of the tree, it is possible to run an 
emergency procedure aiming to reproduce new replicas of this chunk, (m) when 
a peer receives a request for a chunk it does not have it can immediately know if 
the request should be routed to its children or its father. That is, a basic Bloom 
Filter mechanism may allow efficient replica management and request routing. 

The drawbacks include that trees are known to be difficult to maintain in 
dynamic peer-to-peer systems, as other structured peer-to-peer systems. More- 
over, the capacity of leaf peers is unused in the diffusion of live chunks, while 
the peers at the highest levels can be overloaded. Actually, a trade-off should be 
found between the number of leaves and the depth of a tree, which have a direct 
impact on the cost of the Bloom Filter mechanism and on the performances of 
the request routing. Finally, this structure is efficient to diffuse a chunk to all 
peers, but this may be unnecessary because only some replicas of fresh chunks 
should be stored. 

3.1.2 Mesh-Based Turntable 

The second proposal is to build, into every sector, a mesh-based overlay where 
the diffusion of chunks is based on gossip protocols. Every peer has a list of 
peers that it continuously refreshes. Peers exchange messages on a periodic 
manner, these messages may carry chunks or neighborhood information. The 
randomized processes in action in gossip protocol have proved to be both efficient 
and adequate to maintain consistently a given number of replicas in dynamic 
systems [19]. However, determining the adequate parameters for these systems, 
especially the frequency of message exchanges, is not easy. 

In a mesh structure, a challenge consists in ensuring that every peer is close 
to any chunk, so that requests for past chunks can be treated as quickly as 
possible. We propose to use a mechanism based on domination theory. This 
mechanism is somehow similar as the one recently described in [20] . A set 
D C V of vertices in a graph G — (V, E) is called a dominating set if every 
vertex x in V is either an element of D or is adjacent to an element of D. 
Most domination problems are NP-hard problems, so no exact solution can be 
computed in a reasonable time. In our case, a practical distributed solution aims 
to maximize the number of distinct chunks in the neighborhood. The idea is to 
build a domatic partition of the overlay, that is, to determine several distinct 
dominating sets, each dominating set being responsible to store a subset of the 
chunks of this sector. Every past chunk and every peer are associated with a 
color, the number of colors being the partition size. A peer in a color should be 
able to retrieve any chunk associated with this color. So, when a representant 
receives a new chunk, it sends this chunk to the neighbor that has the same 
color, then the diffusion is restricted to peers in this color. Similarly, when a 
request for a past chunk is received by a peer, it should first determine the 
color associated with this chunk, then forward the request to its appropriate 
neighbor. 
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Figure 5: The mesh-based overlay structure 



3.1.3 Discussion 

The advantages of the turntable structure include that every sector should par- 
ticipate at the same level. Because every sector is associated with a chunk unit, 
the portion popularity variation does not impact the sector request load. More- 
over, every sector should store the same amount of chunks. However, the cost 
of maintaining the structure in an efficient manner may be high. Moreover, it is 
not clear that easy incentive mechanism can be implemented in such a structure. 
Note however that, contrarily to previous works, the design of this structure fits 
definitely the characteristics of time-shifted streaming systems. 

3.2 Interval Overlay Structure 

We propose now an overlay structure based on interval graphs. Here, every peer 
is a client that is requesting a past portion of the stream. The idea is that the 
chunks sent to the clients are temporarily stored by the clients, so that other 
peers can request them. 

First, we recall the definition of interval graph. A graph is called an interval 
graph if its vertices can be put in a one-to-one correspondence with a family F 
of intervals on the real line, such that two vertices are adjacent in G iff their 
corresponding intervals have nonempty intersection. Formally, let {Ii, 7 2 , I n \ 
be a set of intervals. A graph G = (V,E) is an interval graph when Vx,y E 
V, {x, y}GE^I x nI y ^9. 

3.2.1 Description 

In peer-to-peer VoD systems, each peer manages a sliding buffer containing 
some past chunks that have been already played and a few chunks that have 
been downloaded in advance. A sliding buffer is at a given time t an interval. 
We define, for every peer x, its interval I x containing a left bound l x , a playing 
position c x and a left bound r x . The value of these parameters are related with 
the source. That is, the interval (l x c x ) contains chunks that will be played (this 
interval may be incomplete, i.e. some chunks may be missing) and the interval 
(c x ,r x ) contains past chunks that have been played (it is expected to be full). 
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Peers connect with the other peers whose buffers overlap. We do not detail 
here the straightforward gossip protocol resulting eventually in that every peer 
is connected with all peers whose buffer overlap. As we previously noticed, the 
challenge of implementing such buffer-based techniques in time-shifted stream- 
ing systems is to ensure that all past chunks are in at least one sliding buffer. 
Our idea is that every peer should adjust its variable l x and r x , so that the global 
overlay respects some conditions. We formulate the problem as an optimization 
problem whose formulation is as follows. 

Actually the size of the buffers should be reduced. Indeed, the management 
of large buffers implies large neighborhood and potentially a large traffic. That 
is, our objective is to minimize the length of the intervals: 

minimize l x — r x 

The first constraint, obvious, is that the resulting interval graph should 
be connected. Furthermore, ensuring a sufficient redundancy requires a k- 
connectivity. In interval graphs, this notion is easier to understand, every chunk 
should be covered by at least k intervals. Formally: 

VtG[0,T},\{x€V:te(l x ,r x )}\>k 

The second constraint is that peers have limited upload capacities. We 
denote by cap(x) the number of peers a peer x can serve. A peer y whose 
left interval (l y ,c y ) overlaps the right interval (c x ,r x ) is a neighbor that x will 
exclusively serve. If x accepts too many peers overlapping its right buffer, it 
will probably experience troubles in serving them. Therefore, we introduce the 
following constraint: 

VxeV,\{yeV: (ly,c v )n( ) ^ 0}| < cap(x) 

It is easy to verify whether it is possible to build an interval graph respecting 
these constraints. Most algorithms for interval graphs are based on an iterative 
exploration of nodes based on their left (or right) interval bound. Here, we 
can use the playing time to iteratively explore the peers from the peers which 
is playing the freshest portion of the stream to the peers requesting the oldest 
stream portion. The k first peers should determine their left bound so that 
the graph is fc-connected. Once these k first left bounds are set, every peer 
determines iteratively their right bounds so that the second constraint is not 
violated. Applying iteratively this process should determine a solution, if any. 
The optimal solution is not guaranteed, though. 

The distributed implementation of this algorithm is also straightforward. A 
gossip protocol ensures that every peer is connected with a neighborhood that 
is beyond the set of peers to which it must be connected. Every event is diffused 
within this neighborhood. Every peer is continuously resetting its parameters 
by running the algorithm from the neighbor whose playing time is the closest 
to the source to the neighbor with the oldest playing position. When a peer 
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crashes or abruptly changes its parameters (e.g., after a VCR operation), the 
gossip protocol should ensure that a new neighbor is added, and the algorithm 
re-runs. 

3.2.2 Discussion 

The advantage of this interval-based overlay is that a peer should not download 
unnecessary chunks (or very few). Based on one-to-one relations, this overlay 
should also support well-known incentive mechanisms. The size of the buffer is 
not fixed, it depends on the popularity of the portion that is requested by the 
peer. In a very popular portion (beginning of a popular show), peers have a 
small buffer and interact with peers whose playing position is very close. On 
the contrary, peers enjoying a unpopular portion may have to manage a very 
large number of chunks. In a practical implementation, some dedicated servers 
may manage these unpopular portions. To the best of our knowledge, this is 
the first time that the management of buffer size aims to satisfy a large set of 
peers. 

4 Conclusion 

Time shifted streaming provides a new attractive service whose implementa- 
tion is quite challgcnging. We have raised two crucial drawbacks having the 
potential to prevent the use of data-centers: scalability and ethics. Although no 
measurement of current time-shifted services have been published yet, we pro- 
pose a conjectural analysis highlighting the main characteristics of this service. 
Then, we describe two peer-to-peer systems: a turntable overlay and an interval 
overlay, both of them being still at the early stage of development. Future works 
include obviously a comprehensive evaluation of their performances. 

Our feeling is that an early publication of the main principles of these over- 
lays should foster fruitful discussions about the numerous issues that should 
still be tackled. In our opinion, previous works have only sketched unconvinc- 
ing solutions. In this paper, the design of the proposed structures is expected to 
address some of the main problems (request of consecutive chunks, allocation of 
chunks, etc.), but we have emphasized that the management of both fresh and 
past chunks is still especially challenging. 

References 

[1] Cisco, "Forecast and methodology, 2008 - 2013," Cisco Systems, Tech. Rep., 
June 2009. 

[2] V. Bush, "As we may think," The Atlantic Monthly, vol. 176, no. 1, pp. 
101-108, July 1945. 



12 



[3] S. Dumais, E. Cutrell, J. Cadiz, G. Jancke, R. Sarin, and D. Robbins, 
"Stuff I've seen: a system for personal information retrieval and re-use," in 
Proc. of the 26th ACM SIGIR, 2003, pp. 72-79. 

[4] J. Gama and M. M. Gaber, Learning from Data Streams: Processing Tech- 
niques in Sensor Networks, 1st ed. Springer, December 2007. 

[5] E. Freeman and D. Gelernter, "Lifestreams: A storage model for personal 
data," SIGMOD Record, vol. 25, no. 1, 1996. 

[6] C. Huang, C. Zhu, Y. Li, and D. Ye, "Dedicated Disk I/O Strategies for 
IPTV Live Streaming Servers Supporting Timeshift Functions," in Proc. 
of IEEE CIT, 2007, pp. 333-338. 

[7] T. Wauters, W. V. de Meerssche, F. D. Turck, B. Dhocdt, and P. Dc- 
meester, "Co-operative Proxy Caching Algorithms for Time-Shifted IPTV 
Services," in Proc. of 32nd Euromicro SEEA, 2006, pp. 379-386. 

[8] J. Zhuo, J. Li, G. Wu, and S. Xu, "Efficient cache placement scheme for 
clustered time-shifted TV servers," IEEE Transactions on Consumer Elec- 
tronics, vol. 54, no. 4, pp. 1947-1955, November 2008. 

[9] W. Xiang, G. Wu, Q. Ling, and L. Wang, "Piecewise Patching for Time- 
shifted TV Over HFC Networks," IEEE Transactions on Consumer Elec- 
tronics, vol. 53, no. 3, pp. 891-897, Aug. 2007. 

[10] F. V. Hccht, T. Bocek, C. Morariu, D. Hausheer, and B. Stiller, "LiveShift: 
Peer-to-Peer Live Streaming with Distributed Time-Shifting," in Proc. of 
8th Int. P2P Conf, 2008, pp. 187-188. 

[11] D. Gallo, C. Miers, V. Coroama, T. Carvalho, V. Souza, and P. Karlsson, 
"A Multimedia Delivery Architecture for IPTV with P2P-Based Time-Shift 
Support," in Proc. of 6th IEEE CCNC, 2009, pp. 1-2. 

[12] X. Hei, C. Liang, J. Liang, Y. Liu, and K. W. Ross, "A Measurement Study 
of a Large-Scale P2P IPTV System," IEEE Transactions on Multimedia, 
vol. 9, no. 8, pp. 1672-1687, Dec. 2007. 

[13] M. Cha, P. Rodriguez, J. Crowcroft, S. Moon, and X. Amatrianin, "Watch- 
ing television over an ip network," in Proc. of Usenix/ACM SIGCOMM 
Internet Measurement Conference (IMC), 2008. 

[14] Y. Hongliang, Z. Dongdong, Z. B. Y., and Z. Weimin, "Understanding user 
behavior in large-scale video-on-demand systems," SIGOPS Oper. Syst. 
Rev., vol. 40, no. 4, pp. 333-344, 2006. 

[15] T. Wauters, W. V. de Meerssche, F. D. Turck, B. Dhocdt, P. Demeester, 
T. V. Caenegem, and E. Six, "Management of Time-Shifted IPTV Ser- 
vices through Transparent Proxy Deployment," in Proc. of IEEE Globecom, 
2006, pp. 1-5. 



13 



[16] Y. Huang, T. Z. J. Fu, D.-M. Chiu, J. C. S. Lui, and C. Huang, "Challenges, 
Design and Analysis of a Large-Scale P2P-VoD System," in SIGCOMM 
Comput. Commun. Rev., vol. 38, no. 4, 2008, pp. 375-388. 

[17] V. Nevena, a. K. N. Gupta Priya, K. Dejan, and R. Antony, "Enabling 
DVD-like features in P2P video-on-demand system," in Proc. of Workshop 
ACM P2P-TV, 2007, pp. 329-334. 

[18] Y. W.-P.K., X. Jin, and C. S.-H.G., "Vmesh: Distributed segment storage 
for pcer-to-peer interactive video streaming," IEEE Journal on Selected 
Areas in Communications, vol. 25, no. 9, pp. 1717-1731, December 2007. 

[19] H. Weatherspoon, H. Miranda, K. Iwanicki, A. Ghodsi, and Y. Busnel, 
"Gossiping over storage systems is practical," SIGOPS Oper. Syst. Rev., 
vol. 41, no. 5, pp. 75-81, 2007. 

[20] A.-M. Kermarrec, E. L. Merrer, Y. Liu, and G. Simon, "Surfing peer-to- 
peer iptv system: Distributed channel switching," in Proc. of Euro-Par, 
2009. 



14 



